Lyra Edwards

The framework was left entirely blank, so everything, including setup, had to be done ourselves. So, after adding SDL to the project, with necessary additions I would need later such as TTF for font, Mixer for sound, and Image for images, I started simply by rendering a blank window that could be closed down by pressing the X button or pressing escape. I then began familiarising myself with SDL by renering an image to the screen, assigned it a rectangle on the screen, and allowed it to be moved with player input.

Over the next few weeks, we covered the basics of creating a 2D game in SDL, I quickly moved to a scene with a basic background and a Mario and Luigi character that could be moved with WASD and the arrow keys, they were affected by gravity and stopped at the bottom of the screen, for now, that was it. So the next big step was making the level interactable. This waas through the use of a level map, at the time this was hard coded, but would later be read in from a file. This checked collision with the players and any other characters in the level so that they would not phase through platforms. This was an efficient way to sort collisions for surfaces that would never change, like the platforms, but tiles could be changed later on if needed, such as the removal of a pow block. This, even with the more complicated code that was required to sort collision on all directions, was better than doing simple box collision every frame. I added a deltaTime variable to keep the game running at a consistent speed, regardless of framerate, and over the next few weeks, built up a very basic version of Mario Bros.

At this point I had a game with Koopas, Coins, two characters, and working collisions. But nothing was animated and the level felt very small. So I sourced a set of sprites for the backgrounds and characters from the original game, and increased the size of the window, this served both to improve the quality and look of the game, while also testing out the flexibility of the level map aspect and collisions. Any hard coded values were adjusted to suit any size screen flexibly, I then animated mario, luigi and the Koopas, and allowed the players to die. The game then looked much better, and as a result of this change, everything was made more modular.

In the final version of the game at the submission date, I had three different enemy variants: Shellcreepers (Koopas): That moved left or right depending on where they spawned, worked their way down the screen, re-emerging at the top when they entered a pipe at the bottom. These were the simplest enemies, so I only awarded 800 points for defeating them. If they were flipped over, either by bumping into the platform from below, or by hitting the POW block, they could be kicked off the stage. If they were allowed to flip back over however, they would become angry, turning red and moving much faster.
The second enemy variant was the SideStepper: A crab that would move much like a Koopa until damaged, at which point it would enrage, moving twice as fast until hit again, where it would flip over and be able to be killed. This enemy would award 1000 points as it was tougher than the Koopa, but would only begin spawning in levels in stage 3 or above. I didn't run into many issues creating this enemy type, the only one I encountered was a need for enemy i-frames to prevent the player from hitting them twice in one bump, but this was simple to implement.
The third and final enmy was the FighterFly: Instead of just charging left or right, it would jump, only moving when in the air,, while relatively slow in comparison to the others, it required precise timing to damage as it could only be hit when it landed. Because of this, it only appears beginning at stage 5, and would award 1200 points.

The game also contained coins that would enter the stage when an enemy was defeated from the pipe on the same side as that enemy, these were all worth 800 points, but would not respawn when entering the pipe at the bottom of the screen, They would simply be removed. Scores for each player could be tracked at the top of the screen, either side of the Top current score, a combined total of the current leading players' scores. Scores were stored in an external scoreboard, any score related data was handled by a ScoreSystem singleton I created, The top score would be displayed, and after the players were killed, they would be taken to a screen where they could input their name and if they scored high enough, they were entered on the board. Only 5 scores are held at a time on the scoreboard, but were saved when exiting the program if there was any changes.

Overall I had a fleshed out version of Mario Bros complete with a scoreboard, animations, sound effects, and multiplayer. I plan on working on this project in future as Ithoroughly enjoyed the development of it, my next steps will be to add any of the original game's features that are not currently present, such as the fireballs, "SlipIce" enemies, and showcase/bonus stages. I believe I have left myself with an adaptable enough framework that this will not be a difficult task, once I have done this, I will add a single player feature, animations to menus, and some original features such as new enemies or powerups. I will then move onto creating more content based off of the infamous Nintendo games

Overall Grade: 1st